本文同步刊載於個人連載網站
Day 4 寫到，我第一次做諮商所預約管理工具時，很早就希望把大部分操作都放進 LINE 裡。
那時候我覺得，使用者本來就會用 LINE，我自己也還不太會做完整前端，如果可以直接靠 LINE 機器人把事情一段一段問完，好像就能先避開很多陌生的介面問題。
但在產品剛開始發想時，前端訓練的 mentor 曾提醒我另一件事：
已經有成熟工具做得很好的事情，不一定要自己重新做一次。
對現在的我來說，這句話很直覺。
但當時我才剛開始做自己的系統，很多事情的第一反應還是：
「這個功能要怎麼做？」
被提醒之後，我才開始多問一題：
這件事情，是不是已經有很好用的工具可以直接拿來用？
最早被我直接拿來用的，就是 Google Calendar。
做預約管理，自然會碰到行程。
一開始，我想的是建立一份所方可以查看的行事曆，把心理師的預約集中起來。
後來又想到：
如果心理師也需要知道自己的預約，難道還要另外再做一個地方讓他查嗎？
那是不是可以直接建立各自的行事曆，再共享給本人？
這樣心理師原本怎麼看 Google Calendar，就可以繼續怎麼看。
不用因為用了我的系統，又重新學一套新的行事曆。
更重要的是，行事曆可以直接跟預約資料同步。
新增預約，就建立行程。
改期，行事曆跟著更新。
取消，原本的行程也一起移除。
原本需要人工做的：
「系統裡改一次，行事曆再改一次。」
就可以直接省掉。
Google Sheets 的情況不太一樣。
那時候我根本還沒有完整的櫃檯 Web 後台。
系統裡雖然已經有資料，但我沒有一個可以讓櫃檯集中查看、搜尋、篩選資訊的介面。
可是櫃檯平常要看的東西很多。
預約資料。
心理師班表和請假。
個案資料。
收費標準。
心理師基本資料。
這些資訊不一定每天修改，但日常工作會反覆查。
所以我想到的是：
既然大家本來就習慣用 Excel 或試算表看資料，那是不是可以把系統裡的最新資料同步到 Google Sheets？
這樣即使我還沒有自己的資料檢視前端，櫃檯至少有一個熟悉的地方可以看。
這裡的 Sheets 主要只是資料檢視介面。
真正的資料還是在系統裡。
正常情況下，直接修改試算表，也不會反過來改掉系統資料。
對我來說，它比較像是在產品還沒有完整前端時，先借一個大家都熟悉的表格來用。
後來繼續討論現場需求時，又有其他工具慢慢加入。
需要備份數位化文件，可以用 Google Drive。
電子收據需要寄給個案，可以用 Gmail。
每日預約狀況希望有摘要，也可以整理後寄出去。
這些不是我一開始就坐下來畫好一張架構圖，決定：
「我的系統要用 LINE、Calendar、Sheets、Drive、Gmail。」
更接近前幾篇一路寫的方式。
先看到一件工作。
開始想能不能更方便。
再發現：
這個能力好像已經有人做得很好了。
於是直接接進來。
這些工具有一個共同點。
它們不只是成熟。
很多使用者本來就會用。
看行程不用重新學。
看表格不用重新學。
收信不用重新學。
找雲端檔案也不用重新學。
所以直接使用它們，省掉的不只是我自己重新開發一套功能的時間。
也省掉了使用者重新學一套陌生工具的成本。
而且有些事情，本來就很適合交給系統自動串接。
預約變了，Calendar 跟著變。
文件產生後，系統自己備份。
收據和摘要，系統自己寄出去。
這些背景工作不需要櫃檯每天反覆切過去操作。
對當時的我來說，這個方向很合理。
做自己的系統，不代表所有能力都要自己重做。
真正讓我開始感覺到問題，是功能幾乎都串好之後，我開始站在櫃檯角度，一項一項實際操作。
LINE 裡不是不能查資料。
如果只找某一筆資訊，可以一步一步問。
但櫃檯有時候需要一次看很多資料。
這時候對話就會變得很長。
所以我會切去 Google Sheets。
Sheets 一次可以看到更多內容，但真的拿來日常操作時，又需要切換不同工作表、篩選欄位，再從很多資料裡找到現在要看的東西。
於是很容易變成：
在 LINE 裡做一段。
切到 Sheets 看資料。
看完，再回 LINE 繼續。
我沒有做完整前端。
櫃檯的操作和資料檢視，也因此被拆到不同地方。
這時候我才開始感覺到：
能看到資料，和能順手完成工作，好像不是同一件事。
每一個工具單獨拿出來都很成熟。
使用者也都知道怎麼用。
但把它們放進同一段工作流程裡，整件事情不一定就會自然變順。
前面的工具選擇沒有因此失去價值。
Calendar 還是適合看行程。
Drive 還是適合放檔案。
Mail 還是適合收資訊。
真正開始變得明顯的是：
把資料接起來，不代表人的工作也一起被接順了。
那麼，系統真正應該接手的，到底是哪些工作？
iThome鐵人賽
看影片追技術